home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
HyperLib 1997 Winter - Disc 1
/
HYPERLIB-1997-Winter-CD1.ISO.7z
/
HYPERLIB-1997-Winter-CD1.ISO
/
オンラインウェア
/
UTIL
/
IIsi-RAM-Muncher フォルダ.sit
/
IIsi-RAM-Muncher フォルダ
/
About the RAM-Muncher
< prev
next >
Wrap
Text File
|
1994-05-11
|
4KB
|
102 lines
IIsi RAM-Muncher INIT
=====================
Written by Paul Ripke <paul.p.r.ripke@bhp.bhpmel04.telememo.au>
An extension to speed up IIsi use without giving slow disk operation.
This extension is for Macintosh IIsi users, running System 7 or greater,
only. The IIsi does not have VRAM, and video circuitry and the CPU must
take turns to access the motherboard-mounted 1Mb that contains the screen
image.
However, this screen image can only be up to around 330K, leaving 700 or
so K for use by applications. Applications loaded into this space will be
very slow, as they can only run when the CPU, and not the video circuitry,
is accessing this bank of RAM.
A standard cure for this is to increase the size of the disk cache to 768K.
This fills the rest of this bank, pushing the applications down into the
other bank. The applications then execute at normal speed. However, a large
disk cache is inefficient, as Apple's disk cacheing is somewhat less than
optimal. And, as the cache only gets accessed by the CPU when the video
is busy elsewhere, you have sped up your applications but slowed your hard
disk.
Adding Macsbug means you can reduce the disk cache size to around 384K, but
this is still not ideal. This extension marks the 1Mb not used by Macsbug or
the screen as unused, so the disk cache lives in the other bank, and you can
have a small, fast disk cache again.
The extension appeared as a posting in the comp.sys.mac.programmer newsgroup.
Here is the original post:
----------
Article 89376 of comp.sys.mac.hardware:
From: paul.p.r.ripke@bhp.bhpmel04.telememo.au (Paul Ripke)
Newsgroups: comp.sys.mac.hardware
Subject: Mac IIsi video and disk cache
Date: Fri, 06 May 1994 10:28:10 +1000
Organization: BHP IT
Message-ID: <paul.p.r.ripke-060594102810@134.18.242.13>
NNTP-Posting-Host: 134.18.242.13
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
In article <2pp2v6$f56@golden.kaleida.com>, Sayeed Ahmed <ahmedss@aol.com>
wrote:
> I have a Mac II si which has four I meg SIMMS plus the one Meg that
> is( I believe) on the motherboard.
> It does not have a seperate Video Card.
>
> The First question that I would like someone to answer
> is Which memory bank is used for the Video here, and...
The video occupies the very top of the "topmost" bank, which happens to be
the 1 meg soldered on the motherboard. As it only occupies about 330K, the
rest of this bank is open for general use (including apps). This results in
quite serious performance problems (personal experience). If you're
interested, I wrote a small INIT which gobbles (most of) the remainder of
that 1 Mb. I have 17 Mb to waste, so I'm not too worried there. It seems to
run faster, but only when using in the "real world". Speedometer and other
speed reporting programs show no change.
I have read resently that upping the disk cache (to about 384K) in the
memory control panel increases performance, particularily vidoe
performance. However I have found that the effects on disk performance
amazing - ie slower than slow. This appears to be mainly due to memory
contentions between cpu during writes and video, as the disk cache is in
the same bank as video.
I have found that keeping the disk cache small with my INIT (see below)
running is quite a good solution.
Now for my INIT. For those that are interested, here's the code:
main()
{
unsigned long x;
x = (unsigned long) BufPtr;
BufPtr = ((char *) ((x >> 20) << 20));
}
What this does is to round BufPtr to the nearest Mb. It could be done with
binary AND, but I got lazy :-)
I'm open to comments as to whether this really works, and if I should be
coming a bit below the Mb boundary. I would love this code to run before
the disk cache is allocated, and macsbug, and anything else, so that the
top bank effectivly becomes VRAM, but I have found no way of doing this.
Any ideas?
----------
[For most users, having rarely-used Macsbug in the 1Mb is reasonable.
Only programmers debugging require the extra speed.]